Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/backend/prisma/seed.ts`:
- Around line 207-210: The "is-employee" rule currently uses operator "contains"
on attribute "user.email", which can match unintended substrings; change it to
an anchored domain match by using a proper operator like "endsWith" with value
"@stack-auth.com" or switch to a regex operator (e.g., "matches") with a pattern
that anchors the domain (such as "@stack-auth\\.com$") so only emails ending in
the company domain are considered internal.

In `@apps/backend/src/app/api/latest/feature-flags/bootstrap/route.ts`:
- Around line 35-48: The version hash is computed from JSON.stringify({ flags:
flagsById, flagIdsByKey, holdouts }) which is sensitive to insertion order;
implement a canonicalization step that deep-sorts object keys (and arrays
deterministically) before stringifying so reordering-only changes don't change
the payload; create or use a helper like deepSortObject and call it on { flags:
flagsById, flagIdsByKey, holdouts } prior to passing into
hashingInternal.murmur3_32 to produce the stable version value used by version.

In `@apps/backend/src/app/api/latest/feature-flags/evaluate/route.ts`:
- Around line 36-38: The request schema currently defines cohorts as
yupRecord(yupString(), yupMixed()) and the handler coerces cohort values with
Boolean(...), which incorrectly turns values like "false" into true; change the
schema to validate cohorts as Record<string, boolean> by replacing yupMixed()
with yupBoolean() (use yupRecord(yupString(), yupBoolean()) for the cohorts
field) and remove any Boolean(...) coercion in the handler so the cohorts object
(symbol: cohorts) is passed through unchanged; make the same change for the
other occurrence referenced (lines 58-60) where cohort values are coerced.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/feature-flags/[flagId]/page-client.tsx:
- Around line 225-282: The save/delete handlers (handleSaveMetadata,
handleSaveVariants, handleSaveRules, handleDelete) currently always show toast
or navigate regardless of whether updateConfig succeeded; useUpdateConfig
returns a boolean result, so await the updateConfig call, check its returned ok
value, and only call toast or router.push when ok is true; if ok is false,
surface an error (e.g., alert or toast with failure) and do not redirect. Ensure
you reference the updateConfig(...) invocation inside each handler and gate
post-success side effects on the returned boolean.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/feature-flags/page-client.tsx:
- Around line 47-55: The current flag factory returns a live-but-unconfigured
flag object (key, type, enabled: true, killSwitch, defaultVariantKey, variants,
rules) which makes non-boolean flags evaluate to undefined; modify the factory
so that when type !== 'boolean' it either sets enabled: false (start as a
disabled draft) or seeds an initial variant and sets defaultVariantKey (e.g.,
create a default entry in variants and assign defaultVariantKey) instead of
leaving defaultVariantKey undefined; update the returned object construction
that builds key/type/enabled/defaultVariantKey/variants to perform this
conditional initialization.

In `@apps/e2e/tests/backend/endpoints/api/v1/feature-flags.test.ts`:
- Around line 11-285: The test suite is missing coverage for two behaviors:
falling back to the authenticated user's id when distinct_id is omitted and
bootstrap revalidation via If-None-Match; add two it tests in this file that use
setupProjectWithFlags and niceBackendFetch: (1) an "/feature-flags/evaluate"
test that authenticates as a user (simulate accessType that ties to an
authenticated user or include an auth header) calls POST without distinct_id and
asserts the returned result reflects that user's id (same deterministic variant
as when you pass distinct_id), and (2) a "/feature-flags/bootstrap" test that
first GETs the bootstrap to capture body.version and then issues a second GET
with an If-None-Match header set to that version and asserts a 304/Not Modified
response (no body) to verify revalidation behavior; place these as additional
it(...) blocks alongside the existing tests referencing niceBackendFetch,
setupProjectWithFlags, and the endpoints "/api/latest/feature-flags/evaluate"
and "/api/latest/feature-flags/bootstrap".

In `@examples/demo/src/app/feature-flags-demo/page.tsx`:
- Around line 15-27: The code silently falls back to empty strings for
NEXT_PUBLIC_STACK_* env vars in evaluateFlags, which masks misconfiguration;
instead, validate apiUrl, projectId, and publishableClientKey at startup (or at
start of evaluateFlags) and throw a clear error if any are missing so the app
fails fast. Replace uses of apiUrl ?? "" / projectId ?? "" /
publishableClientKey ?? "" inside evaluateFlags with the validated non-null
strings (or call a small helper like ensureEnv('NEXT_PUBLIC_STACK_API_URL',
apiUrl)) and propagate/throw a descriptive error if validation fails so the
fetch call never runs with empty/undefined values. Ensure to reference and
update the constants apiUrl, projectId, publishableClientKey and the
evaluateFlags function when making this change.

In `@packages/stack-shared/src/config/schema.ts`:
- Around line 239-291: Add a schema-level test on the feature-flag object (the
schema that contains variants, defaultVariantKey and rules) that collects the
set of variant ids from the variants record and validates that
defaultVariantKey, every rules.*.variantKey, and every key referenced in
rules.*.variantWeights exist in that set; use yup.TestContext (this.createError)
to return clear errors for missing variant ids and reference the existing
symbols: variants, defaultVariantKey, rules, variantKey, variantWeights,
yupRecord and userSpecifiedIdSchema to locate the parent schema; implement the
test as a function that reads this.parent.variants to build the allowed ids,
iterates rules (this.parent.rules) to check each referenced id, and calls
this.createError with appropriate path (e.g. `${this.path}.defaultVariantKey` or
`${this.path}.rules.${ruleId}.variantWeights`) when a missing id is found.

In `@packages/stack-shared/src/feature-flags/evaluator.ts`:
- Around line 205-210: The dependsOn check currently treats only true, non-empty
strings, and non-zero numbers as "met", rejecting JSON objects/arrays; update
evaluateFlag's truthiness logic (the depTruthy computation inside the dependsOn
branch) to use a shared isTruthy helper that returns true for: boolean true,
non-empty strings, non-zero numbers, non-null objects with at least one own key,
non-empty arrays (length > 0); return false for null/undefined/empty
objects/arrays/zero/empty string/false. Replace the inline depTruthy expression
with a call to isTruthy(dep.value) and reuse that helper wherever flag
truthiness is needed (keeping defaultResult("dep_unmet") behavior unchanged).
- Around line 61-67: The evaluator's "regex" branch currently compiles
tenant-supplied patterns on each evaluation (case "regex") which risks ReDoS and
silently swallows pattern errors; change the flow so regex patterns are
validated and pre-compiled at flag creation/update (not in evaluate), store the
compiled/validated RegExp (or a safe-regex wrapper) on the flag object, and in
evaluate use the cached compiled instance's test method without constructing a
new RegExp or relying on a bare catch; also ensure creation/update path rejects
invalid or unsafe patterns (or use a safe-regex library with timeouts) so
evaluate never compiles untrusted input.
- Around line 28-43: The compareSemver implementation is not semver-compliant
because it treats prerelease and build metadata as ordinary sortable tokens;
update compareSemver to parse and compare semver per the spec: split a version
into core (major.minor.patch numeric), prerelease (dot-separated identifiers)
and ignore build metadata entirely, then compare cores numerically, and if equal
treat a version without prerelease as higher than one with prerelease; when
comparing prerelease identifiers apply semver rules (compare numeric identifiers
numerically, non-numeric lexically, numeric < non-numeric, longer list wins only
if all previous equal). Modify the parsing logic in compareSemver and use or
replace stringCompare with the semver identifier comparison rules so that
compareSemver("1.0.0","1.0.0-alpha") > 0 and builds are ignored.

---

Nitpick comments:
In `@apps/e2e/tests/backend/endpoints/api/v1/feature-flags.test.ts`:
- Around line 6-8: The test currently calls Project.updatePushedConfig with a
full nested object (updatePushedConfig({ featureFlags })) which can overwrite
sibling config fields; change the call in setupProjectWithFlags to use path
notation instead (e.g., Project.updatePushedConfig({ "featureFlags":
featureFlags })) so only the featureFlags path is updated and siblings are
preserved.

In `@packages/stack-shared/src/feature-flags/evaluator.ts`:
- Around line 18-25: The helper getDottedAttribute currently bypasses the type
system by casting cursor to Record<string, unknown>; instead, after the
null/object guard inside the loop use Reflect.get(cursor, part) to access the
property without an explicit cast, preserving proper typing for EvalContext and
cursor and returning undefined when the guard fails; update references to
cursor, parts, and attribute accordingly and remove the (cursor as
Record<string, unknown>) cast.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/backend/src/app/api/latest/feature-flags/evaluate/route.ts`:
- Around line 51-69: The evalContext currently allows client-authenticated
requests to supply distinct_id (via the else branch using body.distinct_id),
enabling client-side spoofing; update the else/unauthorized-targeting branch so
distinctId is taken only from auth.user?.id (remove body.distinct_id) and ensure
userId and user fields likewise come from auth (e.g., userId: auth.user?.id and
user built from auth.user), preserving the existing
callerCanSupplyTargetingContext check and leaving the auth.type !== "client"
branch unchanged.

In `@packages/stack-shared/src/feature-flags/types.ts`:
- Around line 25-40: Replace the fragile, hand-rolled ReDoS checks in
getFeatureFlagRegexPatternError with a proven ReDoS-safe engine or validator:
remove or keep only the simple length check (maxFeatureFlagRegexPatternLength)
and instead use a library like re2 or safe-regex to validate the pattern (call
the library from getFeatureFlagRegexPatternError before constructing new RegExp)
so you guarantee linear-time matching; ensure the function returns the
library-provided error message on invalid patterns and still returns undefined
for valid ones.

In `@packages/stack-shared/src/interface/client-interface.ts`:
- Around line 552-568: The evaluateFeatureFlags method currently calls
sendClientRequest without passing the requestType so it always defaults to
client access; update evaluateFeatureFlags to accept a requestType parameter (or
forward an existing one) and pass it as the fourth argument to sendClientRequest
so the X-Stack-Access-Type header reflects the caller (e.g., call
sendClientRequest(..., session, requestType)). Ensure you update the
evaluateFeatureFlags signature and any call sites to supply the appropriate
requestType and preserve existing behavior when omitted.

---

Nitpick comments:
In `@packages/stack-shared/src/feature-flags/evaluator.ts`:
- Around line 71-81: The regexCache Map in getCompiledRegex grows without bound;
implement a bounded LRU-style eviction. Add a constant (e.g., REGEX_CACHE_MAX =
1000) and update getCompiledRegex so that on cache hit you promote the key to
mark it recent (delete then set), and on inserting a new compiled RegExp you
check regexCache.size and evict the oldest entry (use
regexCache.keys().next().value) if size > REGEX_CACHE_MAX; alternatively,
replace the Map with an LRU cache library but ensure getCompiledRegex and the
regexCache symbol behavior are preserved.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/backend/src/app/api/latest/feature-flags/bootstrap/route.ts`:
- Around line 74-83: The current If-None-Match check treats
headers["if-none-match"] as a single string and calls includes(etag), which
misses comma-separated ETag lists; update the comparison in the route so you
parse headers["if-none-match"] into individual entity tags (split on commas,
trim whitespace and surrounding quotes, and handle the wildcard "*" case) and
then check if any parsed tag equals the current etag or version before returning
the 304 response; locate the logic around the if block that references
headers["if-none-match"], etag and version to implement this parsing and
comparison.

In `@apps/backend/src/app/api/latest/internal/config/override/`[level]/route.tsx:
- Around line 301-317: The current flow reads the entire override
(levelConfig.get), merges with override(), validates, then writes the whole
document (levelConfig.set), which is not atomic and can silently clobber
concurrent sibling updates; instead build a path-based partial update from
parsedConfig and apply it with a path/patch API on levelConfig (e.g., use the
service's patch/update-paths method or a set call that accepts dotted-path keys)
rather than reading oldConfig and calling levelConfig.set with the merged
document; keep using assertConfigValidBeforeWrite but validate the specific
path(s) or the resulting merged paths, then call the path-based update
(referencing levelConfig.get, override, assertConfigValidBeforeWrite,
levelConfig.set in your changes) so concurrent updates don't overwrite unrelated
properties.

In `@packages/stack-shared/src/feature-flags/evaluator.ts`:
- Around line 28-45: compareSemver currently falls back to lexicalCompare for
malformed versions which lets bad inputs pass semver_gt/semver_lt; update parse
inside compareSemver so it performs strict validation (core must be three
numeric segments and prerelease parsed deterministically) and if either operand
is invalid return NaN (or another sentinel) instead of calling lexicalCompare,
then update semver_gt and semver_lt to call compareSemver and return false when
the result is NaN (i.e., only return true when compareSemver yields a valid
numeric comparison); ensure you remove the lexicalCompare fallback and apply the
same validation change where compareSemver is duplicated/used around lines
149-158.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/stack-shared/src/feature-flags/evaluator.ts`:
- Around line 150-158: The toMs helper in the "before"/"after" branch currently
uses Date.parse on arbitrary strings which is implementation-dependent; update
the toMs function (used in the "before"/"after" case) to fail closed for string
inputs by only accepting Date objects or numeric epoch values, or if you must
support strings validate against a strict RFC3339/ISO8601 pattern first and only
then parse; return undefined for any non-matching strings so comparisons are
deterministic across runtimes.
- Around line 18-25: getDottedAttribute currently uses Reflect.get which walks
the prototype chain and can return inherited properties; change it to only read
own properties: when iterating parts inside getDottedAttribute, after confirming
cursor is non-null and typeof object, check
Object.prototype.hasOwnProperty.call(cursor, part) (or
Object.getOwnPropertyDescriptor) and if the property is not an own property
return undefined; if it is own, read the value via direct property access (e.g.,
(cursor as Record<string, unknown>)[part]) and continue. This ensures
getDottedAttribute resolves only explicitly provided fields and not inherited
ones.

---

Nitpick comments:
In `@apps/backend/src/app/api/latest/internal/config/override/`[level]/route.tsx:
- Around line 260-264: The PUT handler is running duplicate validation:
assertConfigValidBeforeWrite(levelConfig, {projectId,branchId,config:
parsedConfig}) and then immediately calling warnOnValidationFailure with the
same payload; remove the redundant work by reusing the first validation result
or gating the second call—either have assertConfigValidBeforeWrite return its
validation result and pass that into warnOnValidationFailure (so
warnOnValidationFailure no longer re-runs validation), or only call
warnOnValidationFailure when assertConfigValidBeforeWrite completes successfully
(avoiding a second validation run). Ensure you update references to levelConfig,
parsedConfig, assertConfigValidBeforeWrite, and warnOnValidationFailure
accordingly.
- Around line 59-62: The parameter types currently using `any` (e.g., the
`options.config` in the validate callback and the helper functions like
validateProjectConfigOverride and the other helper at line ~215) should be
replaced with schema-derived types or documented why `any` is required: change
`any` to `yup.InferType<typeof <YourSchemaName>>` (e.g.,
ProjectConfigOverrideSchema) so the validateProjectConfigOverride signature
becomes typed from the schema, or if you cannot due to complex polymorphic
transforms, add a concise inline comment above each function explaining that
runtime validation/normalization makes static typing impractical and why `any`
is used temporarily (include reference to the specific schema used). Ensure you
update all three spots (the validate callback, validateProjectConfigOverride,
and the helper at ~215) to use the same approach and reference the schema symbol
name to keep types consistent.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/feature-flags/page-client.tsx:
- Around line 69-70: config.featureFlags.flags may be undefined, so calling
typedEntries(flags) can break; add a defensive fallback by ensuring flags is an
object/empty map before calling typedEntries (e.g., set flags =
config.featureFlags.flags ?? {}), then compute entries = typedEntries(flags) so
typedEntries always receives a defined value; update the code around the
variables flags and entries in page-client.tsx to use this fallback.
- Around line 140-142: The title prop currently uses a boolean fallback
(title={def.key || flagId}) which treats empty string as absent; change it to a
nullish fallback (title={def.key ?? flagId}) to match the existing nullish check
used for subtitle (def.type ?? "boolean") and keep semantics consistent for
def.key and flagId; locate the title assignment in the component rendering where
title, subtitle are set and replace the || operator with ?? for def.key.
- Line 181: Replace the unsafe cast in the Select onValueChange handler by
adding a runtime type guard for FlagType: define FLAG_TYPES (Set of valid
FlagType strings) and an isFlagType(v: string): v is FlagType function, then
change the handler in Select (the component using newType and setNewType) to
call isFlagType(v) and only call setNewType(v) when the guard returns true; this
removes the use of "as FlagType" and preserves type safety for newType and
setNewType.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@package.json`:
- Around line 101-102: package.json pins runtime "react" and "react-dom" to
19.2.3 while the workspace override forces `@types/react` and `@types/react-dom` to
^18.2.0, causing a major-version mismatch; update the workspace overrides so the
dev/type packages match React 19 (e.g., set `@types/react` and `@types/react-dom` to
the correct major for React 19), or alternatively align the runtime to React 18
if you must keep the existing types—modify the overrides entry for
"@types/react" and "@types/react-dom" (and any related peerDependency entries)
to the matching major version to ensure type/runtime parity across the
workspace.